For SizeChanged, I associated the event with the event handler in XAML, but for OrientationChanged, I overrode the equivalent OnOrientationChanged method.
Of course, you can attach handlers to events entirely in code as well. One handy class for Silverlight programs is DispatcherTimer, which periodically nudges the program with a Tick event and lets the program do some work. A timer is essential for a clock program, for example.
The content grid of the SilverlightSimpleClock project contains just a centered TextBlock:
Example 1. Silverlight Project: SilverlightSimpleClock File: MainPage.xaml (excerpt)
<Grid x:Name="ContentPanel" Grid.Row="1" Margin="12,0,12,0"> <TextBlock Name="txtblk" HorizontalAlignment="Center" VerticalAlignment="Center" /> </Grid>
|
Here’s the entire code-behind file. Notice the using directive for the System.Windows.Threading namespace, which isn’t included by default. That’s the namespace where DispatcherTimer resides:
Example 2. Silverlight Project: SilverlightSimpleClock File: MainPage.xaml.cs
using System; using System.Windows.Threading; using Microsoft.Phone.Controls;
namespace SilverlightSimpleClock { public partial class MainPage : PhoneApplicationPage { public MainPage() { InitializeComponent();
DispatcherTimer tmr = new DispatcherTimer(); tmr.Interval = TimeSpan.FromSeconds(1); tmr.Tick += OnTimerTick; tmr.Start(); }
void OnTimerTick(object sender, EventArgs args) { txtblk.Text = DateTime.Now.ToString(); } } }
|
The constructor initializes the DispatcherTimer, instructing it to call OnTimerTick once every second. The event handler simply converts the current time to a string to set it to the TextBlock.
Although DispatcherTimer is defined in the System.Windows.Threading namespace, the OnTimerTick method is called in the same thread as the rest of the program. If that was not the case, the program wouldn’t be able to access the TextBlock
directly. Silverlight elements and related objects are not thread safe,
and they will prohibit access from threads that did not create them.
The clock is yet another Silverlight program in this chapter that changes the Text property of a TextBlock
dynamically during runtime. The new value shows up rather magically
without any additional work. This is a very different from older
graphical environments like Windows API programming or MFC programming,
where a program draws “on demand,”
that is, when an area of a window becomes invalid and needs to be
repainted, or when a program deliberately invalidates an area to force
painting.
A Silverlight program often doesn’t seem to draw at all! Deep inside of Silverlight is a visual
composition layer that operates in a retained graphics mode and
organizes all the visual elements into a composite whole. Elements such
as TextBlock exist as actual entities inside this composition layer. At some point, TextBlock is rendering itself—and re-rendering itself when one of its properties such as Text changes—but what it renders is retained along with the rendered output of all the other elements in the visual tree.
In contrast, an XNA program is actively drawing
during every frame of the video display. This is conceptually different
from older Windows programming environments as well as Silverlight. It
is very powerful, but I’m sure you know quite well what must also come
with great power.
Sometimes an XNA program’s display is static; the program might not need to update the display every frame. To conserve power, it is possible for the Update method to call the SuppressDraw method defined by the Game class to inhibit a corresponding call to Draw. The Update method will still be called 30 times per second because it needs to check for user input, but if the code in Update calls SuppressDraw, Draw won’t be called during that cycle of the game loop. If the code in Update doesn’t call SuppressDraw, Draw will be called.
.